Complex systems utilize various interfaces for system control and management, where each interface may provide a different method of interfacing with the system. Among such complex systems is a storage server, which is a special purpose processing system used to store and retrieve data on behalf of one or more client processing systems (“clients”) over a network. A conventional storage server includes a storage operating system that implements a file system to logically organize data as a hierarchical structure of directories and files on the disks. A file system is any organization of data in a structured manner, which can be, but is not necessarily, organized in terms of a structured (e.g., hierarchical) set of stored files, directories and/or other types of data containers.
A file server is an example of a storage server that may be accessed using various interfaces. A file server operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage based disks or tapes. The mass storage devices may be organized into one or more volumes of Redundant Array of Inexpensive Disks (RAID). In conventional storage systems, the physical storage devices may be organized into one or more groups of disks (e.g., redundant array of inexpensive disks (RAID)). These disks, in turn, define an overall logical arrangement of storage space, including one or more storage volumes. A storage volume is any logical data set that is an abstraction of physical storage, combining one or more physical storage devices (e.g., disks) or parts thereof, into a logical storage object, and which is managed as a single administrative unit, such as a single file system. A volume may be defined from a larger group of available storage, such as an aggregate. The physical storage device(s) underlying a storage volume may vary in different implementations. In some instances, a storage volume as described herein can be a flexible storage volume, i.e. a volume that is flexibly associated with the underlying physical storage device(s). In other instances, a storage volume as described herein can be a traditional volume, i.e., a volume that is mapped directly and inflexibly to the underlying physical storage device(s).
Another example of a storage server is a device that provides clients with block-level access to stored data, rather than file-level access, or a device that provides clients with both file-level access and block-level access. Data stored by a storage server may be stored in the form of multiple blocks that each contains data. A block is the basic unit used by a file system in a storage server to manipulate and transfer data and/or metadata. A client may use any of various interfaces to access the file server.
A storage server can be used for many different purposes, such as to provide multiple users with access to shared data or to backup mission critical data. The storage system may utilize a set of system interfaces to support various commands and operations to serve its purposes. Both a command line interface and an application programming interface (API) may be utilized to control or manage the storage server, where the command line interface is an interactive process with a user, while the API is generally a non-interactive interface. For a non-limiting example, an API may take one or more required or optional arguments, values, or parameters for its basic functions, wherein the arguments can be passed to or from the interface as inputs or outputs. In one example, an API may provide for marshalling of API name and input parameters using XML (extensible markup language), with input parameters being typed and the contents of the XML being independent of the programming language and architecture on both client and server sides of a transaction, and with the server returning values from the invocation of the API marshaled in the same format as the input.
Program language binding enables an integration developer to obtain a semantic view of the API and to able to focus on using the API method and not on dealing with the underlying message construction and parsing. Providing a language binding that supports upward compatibility of an interface is critical since upgrading to utilize the language binding library for a newer version of the interface must not require any updates to the client side application. A design to map the methods of the interface directly to Java methods does not meet this requirement as the addition of new optional arguments or outputs to an interface's method results in method signature changes, therefore impacting existing client application code. Furthermore, existing interface methods in some cases have large numbers of optional input parameters, making API usage difficult to manage (i.e. which argument goes in which position in the call).